PostgreSQL's MSVC atomics in src/include/port/atomics/generic-msvc.h
rely on _ReadWriteBarrier() (a compiler barrier only, emitting no
instruction) for the compare-exchange primitives, and let read_u64 /
write_u64 fall through to generic.h's plain volatile access.  On x86/x64
that is correct because the ISA is strongly ordered (TSO).

On ARM64 (aarch64), which is weakly ordered, it is not:

  * a plain volatile 64-bit load/store is not an acquire/release; and

  * MSVC may satisfy an interlocked operation with an out-of-line helper
    that, on ARMv8.1 targets, uses an LSE "casal" instruction.  "casal"
    gives acquire/release ordering for that one location but is NOT a
    full fence -- it is weaker than the "dmb ish" that PostgreSQL's
    barrier macros (MemoryBarrier() -> dmb) are expected to provide.

Code that assumes full-fence semantics can then misbehave on Windows
ARM64.  This was reported to Microsoft as an MSVC code-generation issue
(Developer Community feedback 10982137, "MSVC compiler optimization in
PostgreSQL's XLogInsertRecord() function leads to incorrect runtime
behaviour on Windows ARM64"); it is not yet fixed in MSVC.  It is
separately visible on an assert-enabled MSVC/aarch64 buildfarm animal as
a BufferLockAcquire() lockmode assertion under the recovery TAP tests.

Rather than depend on the intrinsics' implicit (and, per the above,
insufficient) ordering, force an explicit full data memory barrier,
__dmb(_ARM64_BARRIER_ISH), on the atomic read, write and compare-exchange
paths on ARM64.  This matches the manual-__dmb workaround demonstrated in
the reduced test case shared with Microsoft.  The directly-defined
exchange/fetch_add helpers are left undefined on ARM64 so generic.h
derives them from the fenced compare-exchange.  All x86/x64 code paths
are unchanged (everything is behind PG_MSVC_ARM64_FENCE).